'ps' related script show error: process ID out of range

I guess this is the spinner that's trying to use PS. I'm not sure, off-hand, how to work around it. A script doesn't need a spinner, but the install script uses a runner tool to do multiprocess stuff, so I don't know if it'll be easy to make it not need to check for running processes.

Installation on CentOS 7 seems to be failed with error, but the script still returns with code 0 (which makes it green)

Where does it fail, specifically? I thought I was passing through error codes, but it's messy with the process running sucking up errors for logging and also absorbing the error code for interpretation.

The log doesn't have much information to debug when error happen

Again, what stage/step does it fail on? It has several indicators in the console output to tell you how far along it is. It may seem mysterious, but if I see the console output and the last few lines of log output, I usually know exactly where it has failed (and if you get familiar with virtualmin-install, slib, virtualmin-config, you will, too).

Rename/replace file /etc/resolve.conf is not possible in Docker container, must alter its content instead

Why do you believe it can be modified but not replaced? Have you tried it? I don't see how one could be possible and the other not. Most safer implementations of "modify a file" do so by copying.

'ps' related script show error: process ID out of range

I guess this is the spinner that's trying to use PS. I'm not sure, off-hand, how to work around it. A script doesn't need a spinner, but the install script uses a runner tool to do multiprocess stuff, so I don't know if it'll be easy to make it not need to check for running processes.

It seems variable $$ reports a pid that ps can't work with. Executing the script after starting the container makes this error disappear. I'll make a discussion on Docker forum.

Installation on CentOS 7 seems to be failed with error, but the script still returns with code 0 (which makes it green)

Where does it fail, specifically? I thought I was passing through error codes, but it's messy with the process running sucking up errors for logging and also absorbing the error code for interpretation.

The log doesn't have much information to debug when error happen

Again, what stage/step does it fail on? It has several indicators in the console output to tell you how far along it is. It may seem mysterious, but if I see the console output and the last few lines of log output, I usually know exactly where it has failed (and if you get familiar with virtualmin-install, slib, virtualmin-config, you will, too).

If you can give a look on the build result, you'll find my issues easily. Sorry that I am new to virtualmin source code (I have been being its user for years, and want to have a chance to contribute).

Rename/replace file /etc/resolve.conf is not possible in Docker container, must alter its content instead

Why do you believe it can be modified but not replaced? Have you tried it? I don't see how one could be possible and the other not. Most safer implementations of "modify a file" do so by copying.

This is by Docker's design. I've tried, to confirm your question. Is it still safe to make a file copy before modify its content?

Nice, I didn't realize this was here, I made something 5 min ago that test on many OS using docker. #60

@trinhpham My first crude attempt at multi OS test install is #61

The migration & new price model of Travis-CI are not very supportive to developer. I deleted my whole account already.
For big OSS project like this, after enabling, the owner might need to request extra credits to be able to cover project build time.
Circle-CI is getting my intention now, @chris001
Let me know if there's thing I could help.

Oops, sorry, I commented on the wrong one.

It's nice to know that you are interesting in this again @swelljoe .
We can limit the test scope by using job.include, or comment out the whole defined OSes then uncomment and fix issue one by one. This is not a big deal.
AFAIK, virtualmin is not container friendly yet. To make this kind of test works, we need one that has deep understanding about most of components and able to get them containerized. This is the big one, we can't go without commitment from dev team.

The migration & new price model of Travis-CI are not very supportive to developer. I deleted my whole account already. For big OSS project like this, after enabling, the owner might need to request extra credits to be able to cover project build time. Circle-CI is getting my intention now, @chris001 Let me know if there's thing I could help.

If you could get your test yml script running on Circle CI, or on any free CI that supports docker container for running the install script on all OS, that would be great!

FYI, there are two kinds of test:

1. The installer script syntax validation (which presents in folder t)

I think your PR #61 will help, but not reduce much testing effort for the development team.

3. The actual installation to verify everything just works

IMO, this is the actual pain point. From the last thing I tried, I was able to install virtualmin 6 components onto a systemd-enabled docker container (the one from jrei ), observed that services are running. But failed at Phase 3, Configuring Net, due to unable to replace file /etc/resolve.conf (I've just re-run and confirm that the problem still exist). This is the only blocker issue which prevents us running the installation test on Docker so far. I had to stop here since I don't have enough time & skills to figure out all places that touch the file (not only in this installer script, but also in webmin package and maybe more).

Correct me if I am wrong.

We no longer update resolv.conf (it was kinda fragile and used for a kinda unimportant feature). So, that pain point goes away.

Exactly @trinhpham the simple goal is to run the install script and see if it can get all the way to the end, and return a 0 code, for success, it just works. Anything other than zero, and Travis flags the build as a "fail", devs should get notified to look at the output, see what happened, and fix whatever was wrong (missing package, broken repo for that particular distro, etc). Next step, would be to enhance the script, to auto check the webmin service is up and running inside the docker container, and that it's correctly answering http and https requests on the default port.

We no longer update resolv.conf (it was kinda fragile and used for a kinda unimportant feature). So, that pain point goes away.

I don't think so. Looking to the installer script at L484, there are sed -i command which actually alter the resolv.conf file in the way that Docker dislikes.
Even if I comment out that line, the installer will still fail at Phase 3, Configuring Net by the same error.
I mentioned it in the past already

This is by Docker's design.

That's --uninstall. How is that code even being run on an install?

The addition to resolv.conf comes in Virtualmin-Config, not the install script. but, apparently we are still adding it there even in Virtualmin 7. I thought Ilia had removed it, but I guess he thought I'd removed it. Dang. I'll fix it this weekend.

To work around the fail at phase 3 Configuring Net, maybe need to use --dns parameters during container starting, to override/reconfigure the DNS settings. See details: Configure DNS in Docker